Various implementations and uses of virtual machines (VMs) are known in the art. In general, a virtual machine (VM) is a software implementation of a machine (e.g., a processor-based device, such as a computer) that executes programs like a physical machine. Conventional VMs are typically separated into two major categories based generally on their use and degree of correspondence to any real machine: 1) a system VM (or hardware VM), and 2) a process VM. Conventional system VMs provide a complete system platform which supports the execution of a complete operating system (OS), as well as other software applications that may execute within the VM. In contrast, conventional process VMs are designed to run a single program, which means that it supports a single process.
A characteristic of conventional VMs is that the software running inside a given VM is limited to the resources and abstractions provided by the VM, i.e., the software cannot break out of its virtual world. Conventional system VMs allow the sharing of the underlying physical machine resources between different VMs, each running its own OS. Thus, a physical machine provides resources (e.g., processing resources, memory resources, networking resources, etc.), which are allocated among various VMs that may be created. The software layer that typically provides the virtualization is generally called a virtual machine monitor (VMM) or hypervisor. As discussed further below, conventional hypervisors can run on bare hardware (which are sometimes referred to as Type 1 or native VM) or on top of an OS (which are sometimes referred to as Type 2 or hosted VM).
Various uses for deployment of VMs within a system have been recognized. For instance, many benefits may be achieved through deploying VMs within a system, whereby physical resources of the system are allocated for supporting such VMs. It may be desirable, for example, to employ VMs in certain systems to achieve one or more of the following advantages: a) multiple OS environments can co-exist on the same computer, in strong isolation from each other; b) the VM can provide an instruction set architecture (ISA) that is somewhat different from that of the real machine; and c) application provisioning, maintenance, high availability and disaster recovery may be enhanced through use of VMs.
Multiple VMs may be created on a physical host system. The host system provides the underlying physical resources that are allocated among and used by the VMs. As discussed above, the VMM or hypervisor generally defines/allocates the resources of each VMM, where the underlying physical resources of the host system are used to support the operations of each VM. For instance, as each VM engages or utilizes the “virtual” resources that are visible to it, the underlying physical resources of the host system that are allocated to the VM are engaged or utilized to support/enable the VM's desired function. For instance, the multiple VMs running on a host system may each run their own OS (each called a “guest” OS) and/or other software applications, wherein each VM may use the “virtual” resources that are visible to it to perform operations that are, in turn, supported/enabled by the underlying physical resources of the host system that are allocated to such VM.
For instance, multiple VMs each running their own guest OS are frequently used in server consolidation, where different services that previously ran on individual, separate physical host systems in order to avoid interference are instead run in separate VMs on the same physical host system. The physical host system that provides the underlying resources for VMs is often a single computer, such as a single server, but the host system may be implemented as any aggregation of underlying resources, such as may be provided by a cluster of computers.
The desire to run multiple OSes was the original motivation for conventional VMs, as it allowed time-sharing a single computer between several single-tasking OSes. The guest OSes do not have to be all the same, making it possible to run different OSes on the same host system (e.g., Microsoft Windows and Linux, or older versions of an OS in order to support software that has not yet been ported to the latest version). The use of conventional VMs to support different guest OSes has become popular in embedded systems. One exemplary use is to support a real-time OS at the same time as a high-level OS, such as Linux or Windows. Another use is to sandbox an OS that is not trusted, possibly because it is a system under development. VMs may provide other advantages for OS development and/or other software development, including better debugging access and faster reboots.
Accordingly, the conventional concept of virtualization in information processing systems allows multiple instances of one or more OSes to run on a single host system (which provides the underlying physical resources), even though each OS is designed to have complete, direct control over the system and its resources. Conventionally, virtualization is typically implemented by using a VMM or hypervisor to present to each guest OS a VM having virtual resources, including one or more virtual processors (and other virtual resources, such as networking resources, memory resources, etc.), that the VM's guest OS may completely and directly control, while the VMM maintains a system environment for implementing virtualization policies such as sharing and/or allocating the physical resources of the host system among the VMs (the “virtualization environment”). Each OS, and any other software, that runs on a VM is typically referred to as a “guest,” while software, such as a VMM, that runs outside of the VMs (i.e., directly on the host system) and/or the physical resources of the system (as opposed to the virtual resources that are visible to the VM) are typically referred to as a “host.”
A host system (which may be referred to as a data processing system) may include various hardware resources, such as one or more central processing units (CPUs), random access memory (RAM), read-only memory (ROM), network access interfaces (e.g., network interface cards), etc. The host system may also include software resources, such as a basic input/output system (BIOS), a virtual machine monitor (VMM), and one or more host OSes.
A VMM is a software program that executes on the host system and controls its physical computer hardware and presents programs executing within a VM with the illusion that they are executing on real physical computer hardware. Each VM typically functions as a self-contained platform, controlled by a “guest” OS, i.e., an OS hosted by the VM, which executes as if it were running on a real machine instead of within a VM. Thus, a conventional VM architecture logically partitions a physical host system, such that the underlying hardware of the host system is time-shared and appears as one or more independently operating VMs.
Conventionally, when a host computer system is started or reset, it loads its BIOS, and then the VMM. A host OS may be started, and then the VMM may be launched on top of the host OS. Alternatively, the VMM may include the control logic necessary for interacting with hardware without an underlying host OS. In this alternative case the VMM is itself an OS kernel, most typically a UNIX/LINUX variant, which starts/boots after POST of the hardware. Thus, the VMM launches its own OS to create VMs. In either case (where a host OS is started and then the VMM is launched or where the VMM itself is an OS kernel), an OS-level program (which is referred to herein as application-level software), i.e., the VMM, is required to be employed after BIOS/POST of the underlying physical host system to create the VMs. The VMM may create and manage one or more VMs, and the VMs may boot to different guest OSes or to different instances of the same guest OS.
Thus, a VMM may effectively allow multiple OSes and software applications to run in independent partitions or execution environments that are defined by the VMs. The CPU(s) and other physical resources in the host system may provide hardware support (e.g., instructions and data structures) for virtualization. Furthermore, different types. of processors may provide different features for supporting virtualization.
Conventionally, the host system (providing the underlying physical resources for VMs) is required to complete its boot process, including completion of its BIOS and POST, and then launch a host OS (or some other application-level program, such as a VMM). Upon a startup of a physical host machine, a boot sequence may be used to boot the host system, which may bring up the host OS and/or VMM to create one or more VMs. As mentioned above, each VM may then run a “guest” OS within it.
As is well-known in the art of computing, booting of a host system generally includes a pre-boot sequence, such as performance of an initial power-on self-test (POST), followed by the system's boot sequence or “bootstrapping” (e.g., via the system's BIOS), which is typically followed by loading of upper-level (control software, such as a host OS. POST generally refers to routines that run immediately after power is applied, by nearly all electronic devices. The routines are part of a device's pre-boot sequence. Once POST completes successfully, bootstrapping code is invoked. Routines included during POST typically include routines to set an initial value for internal and output signals and to execute internal tests, as determined by the device maker. These initial conditions are also referred to as the device's state. They may be stored in firmware or included as hardware, either as part of the design itself, or they may be part of semiconductor substrate either by virtue of being part of a device mask, or after being burned into a device such as a programmable logic array (PLA).
Test results may be enunciated either on a panel that is part of the device, or output via bus to an external device. They may also be stored internally, or may exist only until the next power-down. In general, POST protects the bootstrapped code from being interrupted by faulty hardware. Diagnostic information provided by a device, for example when connected to an engine analyzer, depends on the proper function of the device's internal components. In these cases, if the device is not capable of providing accurate information, subsequent code (such as bootstrapping code) may not be permitted to run. This is done to ensure that, if a device is not safe to run, it is not permitted to run.
Once the POST is passed, the host system's boot sequence or “bootstrapping” code is invoked. Conventionally, bootstrapping or “booting” of a host system generally refers to a technique by which a simple computer program activates a more complicated system of programs. In the start up process of a host system, a relatively small program, such as the system's basic input/output system (BIOS), initializes and tests that the system's hardware resources (e.g., including its peripherals and external memory devices, etc.) are connected.
The host system's BIOS is generally a de facto standard defining a firmware interface (sometimes referred to as the “boot firmware”). The BIOS software is commonly built into the host system's hardware (e.g., ROM), and is the first code run by the host system when powered on (following the above-mentioned POST). Conventionally, the primary function of the BIOS is to load and start a higher-level program (referred to herein as an application-level program), such as an OS. Thus, a host system's BIOS is typically a basic or fundamental low-level software that the system's hardware autonomously knows to invoke upon start-up, typically to load and start a higher-level program such as an OS. As is well-known, when a host system starts up, the first job for the BIOS typically is to initialize and identify system devices such as the video display card, keyboard and mouse, hard disk, CD/DVD drive and other hardware resources of the system. The BIOS then locates software held on a storage resource of the system (often designated as a “boot device”), such as a hard disk or a CD, and loads and executes that software, giving it control of the host system. This process is known as booting, or booting up, which is short for bootstrapping.
Typically, the BIOS software is specifically designed to work with the particular type of system in question, including having a knowledge of the workings of various devices that make up the complementary chipset of the system. In modern computer systems, the BIOS chip's contents can be rewritten allowing BIOS software to be upgraded. The BIOS typically provides a small library of basic input/output functions used to operate and control the peripherals such as the keyboard, text display functions and so forth, and these software library functions are callable by external software. In the IBM PC and AT, certain peripheral cards such as hard-drive controllers and video display adapters carried their own BIOS extension ROM, which provided additional functionality. OSes and executive software, designed to supersede this basic firmware functionality, often provide replacement software interfaces to applications.
Conventionally, VMs are created on a host system after the host system has completed its POST and boot sequence (by its BIOS) and has thus loaded an application-level software program (e.g., the host OS) on the host system. Conventionally, the host OS initializes on the host system, and then some software application executes to create a VM environment, such as the Windows Virtual PC application available from Microsoft or VMware vSphere available from VMware. Alternatively, other application software (e.g., a VMM application that itself is an OS kernel) may be launched after the POST and BIOS completes in addition to or instead of the host OS, and such application-level application program (e.g., VMM application) may be used to create the VM environment.
Multiple VMs can be created on a single host physical machine. With some more advanced OSes, multiple independent systems (each with their own host OS) may be clustered, thereby forming a host system on which multiple VMs may be created/hosted. Conventional VMs also depend on the application-level software program (e.g., host OS or VMM application) that is launched on the host system to instruct the VM as to its available/visible resources. Accordingly, in conventional deployments, the host system must be fully booted (e.g., the POST and BIOS completes and an application-level control program, such as the host OS and/or a VMM application that is itself an OS kernel, is launched by the BIOS) before a VM can be created.
FIG. 1A shows an example of a conventional implementation of VMs deployed on a host system. In this example, a host system 100 provides physical resources, such as CPU(s), memory, network interface, and/or other resources, which are shown generally as a physical resource pool 101. The physical resource pool 101 includes ROM that has stored thereto the system's BIOS code 111, which controls the boot-up process of the system for launching an application-level software program, such as the host OS 102, to which control of the system is passed. The host OS 102 may be Windows, Linux, or other suitable OS, as examples. In certain systems, a VMM which itself is an OS kernel may be launched instead of a host OS 102, but in either case such a VMM or host OS 102 are application-level software that is launched following the completion of the BIOS boot-up sequence for managing the resource pool 101 and/or the creation of VMs.
In the illustrated example of FIG. 1, a VM creation/management application 103, such as the Windows Virtual PC application for example, is launched for creation of VMs on the host system 100. For instance, VMs VM1, VM2, and VM3 are created by the VM creation/management application 103 in this example. As shown, each of the VMs may have a respective guest OS residing therein, such as guest OSes 1041-1043. Further, each VM is allocated (e.g., by the VM creation/management application 103) certain virtual resources that are visible to the VM. For instance, VM1 is allocated virtual resources 1051, VM2 is allocated virtual resources 1052, and VM3 is allocated virtual resources 1053. The pool of physical resources 101 of the host system 100 are used to support/enable the operations of the VMs that are performed on their respective virtual resources, in a manner as is well-known within VM architectures.
FIG. 1B shows an operational flow diagram for creation of VMs in a conventional host system, such as that of FIG. 1A. In operational block 120, the host system 100 is powered on. That is, the physical resources 101 of the host system 100 are powered on. In block 121, BIOS 111 controls the boot sequence of the host system 100. In booting the system, the BIOS 111 typically performs various hardware identification, checks, and initialization operations 122, performs POST operations 123, then loads/launches 124 an application-level control program, such as a host OS 102, and then transfers 125 control to the application-level control program (e.g., host OS 102). In block 126, a VM creation/management application 103 is loaded/executed on the host system 100, and in block 127 the VM creation/management application 103 creates VMs (such as VM1-VM3) on the host system 100.
Various conventional VM architectures and implementations are further disclosed in U.S. Patent Application Publication No. 20100325278, U.S. Patent Application Publication No. 20100306774, U.S. Pat. No. 7,865,762, U.S. Pat. No. 7,865,670, and U.S. Pat. No. 7,865,712, as examples.